Resource Dependency Manager Pattern

ion: services and quality of service. In the simplest case, a Dependency Description simply lists the other resources a resource depends on. This means that the dependencies refer to specific software or hardware components. For greater flexibility, it is possible to specify the abstract service types a resource provides. For example, the Dependency Description of an application that displays its on-line documentation in HTML format could refer to the abstract service type WebBrowser rather than the concrete resource Netscape. In this extension, a Dependency Description becomes more general. It does not only include a resource’s required services, but also the services it provides to other resources. In order to distinguish between different implementations of a service, the resource’s provided services may be described using QoS attributes. In the same fashion, the required resources can be specified more closely using boolean predicates over these attributes, or numeric expressions for optimization. This extension is used in DWARF, where components describe what they provide by Abilities and what they require by Needs. Abilities have attributes which can be matched by the needs’ boolean expressions. It is also used in RPM, which has requires and provides fields in package descriptions. Simple attributes and predicates are available in RPM, e.g. to specify a minimum compiler or API version. The introduction of service types can be used in open and mobile systems with service discovery to adapt the system to changes in the availability of services over time. But such a solution is more complex and less robust. The overall problems are service naming and compatibility. First, service user and service provider must agree on the same name for a particular service. This can be solved by service specifications by organizations such has the Internet Engineering Task Force (IETF). The second problem is that once a service provider has been found, it is not clear if it really implements what it promises. Support for Design by Contract. In Design by Contract [5], preconditions for the use of software resources are made explicit, as well as postconditions that hold after use, if the preconditions have been met. These preconditions and postconditions are specified explicitly, usually taking advantage of special programming language features. The preconditions and postcondition create a contract between the caller of a method and the object implementing that method. A resource’s dependencies on other resources can be modelled as a simple contract. The method in question is a resource’s start() method. Its precondition is the availability of other resources, as specified in the Dependency Description. Its postcondition is the availability of the resource itself. Thus, a contract exists between the Resource Lifecycle Manager and each resource. Only if the Resource Lifecycle Manager can provide all required resources with the required quality, then a resource can start and provide its own services. Beyond that, the Resource Lifecycle Manager sets up a graph of simple contracts between the resources themselves when it initializes and connects them. These contracts are based on the same simple preconditions, the availability of a resource and its services. Using attributes and predicates to model quality of service as described above, the preconditions and postconditions can become more complex. Thus, an extended version of the Resource Dependency Manager pattern can benefit from a design by contract approach, where the preconditions and postconditions are made explicit in the form of Dependency Descriptions. A general solution to negotiating collaborations between distributed designed-by-contracts software components is an area for future research. Support of component-specific communication methods. Traditional middleware technologies such as CORBA [7] or COM+ [6] do not support heterogenous means of communication, e.g. video streams and method calls. To adapt the system’s transport facilities to the requirements of the resources, the Dependency Descriptions can include the supported communication mechanisms. The Resource Lifecycle Manager can then establish appropriate communication channels. This approach is used in DWARF.